1. Technical Field
This invention generally relates to object oriented programming and more specifically relates to a mechanism and method for instantiating domain-neutral objects with suitable domain-specific run-time extensions in an appropriate collection.
2. Background Art
The development of the EDVAC computer system of 1948 is often cited as the beginning of the computer era. Since that time, computer systems have evolved into extremely sophisticated devices, and computer systems may be found in many different settings. Computer systems typically include a combination of hardware, such as semiconductors and circuit boards, and software, also known as computer programs. As advances in semiconductor processing and computer architecture push the performance of the computer hardware higher, more sophisticated computer software has evolved to take advantage of the higher performance of the hardware, resulting in computer systems today that are much more powerful than just a few years ago.
Computer systems typically include operating system software that controls the basic function of the computer, and one or more software application programs that run under the control of the operating system to perform desired tasks. For example, a typical IBM Personal Computer may run the OS/2 operating system, and under the control of the OS/2 operating system, a user may execute an application program, such as a word processor. As the capabilities of computer systems have increased, the application software programs designed for high performance computer systems have become extremely powerful. Additionally, software development costs have continued to rise because more powerful and complex programs take more time, and hence more money, to produce.
One way in which the performance of application software programs has been improved while the associated development costs have been reduced is by using object oriented programming concepts. The goal of using object oriented programming is to create small, reusable sections of program code known as "objects" that can be quickly and easily combined and re-used to create new programs. This is similar to the idea of using the same set of building blocks again and again to create many different structures. The modular and re-usable aspects of objects will typically speed development of new programs, thereby reducing the costs associated with the development cycle. In addition, by creating and re-using a comprehensive set of well-tested objects, a more stable, uniform, and consistent approach to developing new computer programs can be achieved.
A central concept in object oriented programming is the "class." A class is a template that defines a type of object. A class outlines or describes the characteristics or makeup of objects that belong to that class. By defining a class, objects can be created that belong to the class without having to rewrite the entire definition for each new object. This feature of object oriented programming promotes the reusability of existing object definitions and promotes more efficient use of program code.
Frameworks are relatively recent developments in object oriented programming that provide a group of pre-packaged classes and class relationships that are designed to help a user easily extend the framework to write a particular software program, such as a software application. One framework that is commercially available from IBM is known as San Francisco, which provides pre-defined classes that allow a user to easily extend the framework to define a custom software application, such as a general ledger or an order processing system. San Francisco defines a special type of domain-neutral object mechanism known as a Hierarchy Level Information Life Cycle Managed Item, referred to herein for the sake of simplicity as an extensible item. An extensible item can be dynamically reconfigured at run-time by adding or deleting domain-specific extensions to the extensible item object. An extensible item that holds a particular primary extension logically becomes an object of the type defined by the primary extension, thereby becoming domain-specific. In this manner the extensible item, which is domain-neutral, can acquire domain-specific extensions that define behavior that allows the extensible item to function as though it were domain-specific itself.
Two considerations come into play in determining how to best create an extensible item. One is whether or not the created object is domain-neutral, and the second is whether or not the created object is placed in an appropriate collection. It would be advantageous to keep the extensible items domain-neutral, which would allow the extensible item to be used as a pure mechanism that knows nothing about any particular domain. It is also desirable to place each extensible item in an appropriate collection when it is created. Different collections are often needed to map data in a collection to an underlying database. This prevents the undue mixing of different types into one collection, thus enabling both efficient layout of various domain-specific database tables (one per primary extension type) and also efficient querying against those tables.
Creating an extensible item using common object oriented techniques has drawbacks. One possible way of creating an extensible item for a particular domain is shown in FIG. 2. A DomainSpecificExtensibleItem class is defined by subclassing from an appropriate DomainInterface class (such as order item interface in an order processing system), and by also subclassing from the ExtensibleItem class. In addition, an ExtensibleItemFactory is subclassed to achieve a DomainSpecificExtensibleItemFactory. The result is a DomainSpecificExtensibleItem class and a DomainSpecificExtensibleItemFactory class that can be used to create the DomainSpecificExtensibleItem objects for a particular domain. The advantage of this approach is that each DomainSpecificExtensibleItem is stored in an appropriate collection, represented by the DomainSpecificExtensibleItemCollection class. The drawback of this approach is that the domain specific extensible item and factory are domain-specific, which means that they no longer function as pure mechanisms, but instead have knowledge about their domain. This approach also causes the need for a different subclass for each type of DomainInterface, which could lead to a large number of new subclasses.
Another way to create an extensible item is shown by the class diagram of FIG. 3. Using this method, the extensible item maintains its domain independence by placing all domain-specific information in the domain extension, but all of the extensible items are created in the same collection, represented by the ExtensibleItemCollectionDefaultForAllExtensibleItems class. Having all of the extensible items in the same collection may make it very difficult to map the data to an existing database table. Without a mechanism for creating mechanism objects that are domain-neutral in appropriate collections, the computer industry will continue to suffer from object oriented frameworks that do not fully take advantage of their potential flexibility and performance.